home *** CD-ROM | disk | FTP | other *** search
Text File | 1996-09-19 | 5.4 KB | 87 lines | [TEXT/ttxt] |
- OpenDoc
- Development
- Framework
-
- Known Problems
- ODF Release 2
-
- The following is a list of the known problems in this release of ODF. This includes the Radar Bug Tracking number,
- the bug title, details of the problem, and, in some cases, a workaround.
-
-
- Bug Number
- <Description>
-
-
- 1378964
- ODFHello clones itself when it gets selected and then moved.
-
- To reproduce: embed ODFHello in ODFDraw or ODFContainer. Activate ODFHello, then click inside it (not in the
- border) and drag. A new copy of ODFHello is created.
-
- What's happening is that the text in ODFHello is draggable, and if there are no other editors installed that handle text,
- a new Hello part is created for the dropped text.
-
-
- 1342662
- Holding down Cmd-z undoes once, but menu flashes repeatedly
-
- The menu bar flashes repeatedly as if Undo was chosen many times, but Undo is performed only once.
-
-
- 1357781
- FW_CString::ParseAsUnsignedInteger should return a boolean
-
- It would be nice to have a version of ParseAsUnsignedInteger et al. that returns true if the number is valid.
-
-
- 1361922
- ODF part should activate after undoing drop/paste of a part
-
- Do the following: launch ODFDraw, drop an ODFClock, activate it, Undo the drop. We end up in a strange state with
- only the OpenDoc menus available. (Clicking in ODFDraw restores its menus.)
-
-
- 1366914
- Command Undo/Redo should validate frames
-
- FW_CCommand has two frame members, fFrame and fSourceFrame. If a command is created from a part being viewed
- in a separate window, fFrame will be the frame in the window and fSourceFrame will be the original embedded frame.
- If the user closes the window, fFrame will not point to a valid frame. If the user then does Undo or Redo, the command
- may dispatch from the invalid frame pointer, causing a crash or exception to be thrown.
-
-
- 1367483
- Localization of number strings
-
- FW_CString::ParseAsRealNumber should do localizable number formatting.
-
-
- 1378789
- Menu id assignment has builtin limit
-
- When menus are first created, they are assigned a menu id of 255, which is the unattached value. When a menu is attached
- to the menu bar it is assigned the next unused menu id. The variable fNextMenuID contains the next unused menu id, and
- it is simply incremented on each assignement. If fNextMenuID reaches 255 no more menu ids can be assigned. A part that
- does a lot of attaching and detaching of menus could hit this limit.
-
-
- 1384628
- MenuBar::GetItemString locale info is not usable for comparing strings
-
- This is actually an OpenDoc bug. The string returned from GetItemString has the following locale: (-1, 0) for System script,
- and (script, 0) for other scripts. The language code is always 0. The effect of this bug is that if you get a string from a menu
- and compare it with another string, they won't match because the locales are different. This is particularly a problem with
- Font menus containing font names in other scripts.
-
-
- 1385382
- FW_CEditView::GetFont returns non-localized font name
-
- If you call FW_CEditView::GetFont(ev)->GetFontName(ev, fontName), the fontName string has a locale of
- (system script, system language) regardless of the font's actual script.
-
-
-
- © 1993 - 1996 Apple Computer, Inc. All rights reserved.
- Apple, the Apple Logo, Macintosh, and OpenDoc are trademarks of Apple Computer, Inc., registered in the United States and other countries.